A virtual machine (VM) is an abstraction—a “virtualization”—of an actual physical computer system. FIG. 1 shows one possible arrangement of computer system 70 that implements virtualization. In this arrangement, a plurality of VMs 20, . . . 20-n is abstracted by virtualization software 15 on a host 10. In the present example, virtualization software 15 includes a VM kernel 60 and one or more VM monitors (VMMs) 50. Other configurations are possible to provide virtualization functionality as generally understood in the art. Host 10 typically includes one or more processors 11, memory 13, some form of mass data storage 14, one or more network interface cards (NICs) 17 and various other devices 19. As generally known, the term “NIC” commonly refers to components implementing a network connection regardless as to whether it exists on a separate card or is integrated with a main computer board.
Each VM 20, . . . 20-n can be thought of as including both virtual system hardware 22 and guest system software 30. Virtual system hardware 22 typically includes one or more virtual processors 28, virtual memory 23, at least one virtual disk 24, and one or more virtual network interface card(s) (VNICs) (only one shown). One or more additional virtual devices 27, such as virtual user interface devices, universal serial bus (USB) ports, etc., may also be included. Virtual system hardware 22 is shown in FIG. 1 in a dashed box because it is merely a conceptualization that does not exist apart from virtualization software 15 and host 10. This conceptualization is merely one representation of the execution environment of guest system software 30. All of the virtual hardware components of VM 20 are actually implemented by virtualization software 15 using known techniques to emulate the corresponding physical components. In the present example, virtualization software 15 includes one or more VM monitors (VMMs) 50 which each include device emulators 53.
Guest system software 30 includes guest operating system (OS) 32 and drivers 34 as needed for VNIC 25, virtual disk 24 and other various virtual devices 27. Guest OS 32 may be an off-the shelf OS designed to run directly on a hardware platform (i.e., not in a virtual machine) or it can be an OS specially modified to run in a para-virtualized environment, depending on what is required or permitted by the particular implementation of virtualization software 15. The term “virtualization software” therefore refers herein to a software layer implanting either full virtualization or para-virtualization. “Full virtualization” refers to a system in which no software components of any form are included in the guest other than those that would be found in a non-virtualized computer; thus, the guest OS could be an off-the-shelf, commercially available OS with no components included specifically to support use in a virtualized environment. In contrast, a “para-virtualized” system is not “fully” virtualized. Rather, the guest is configured in some way to provide certain features that facilitate virtualization. For the purposes herein, the term “virtualization” includes both full and para-virtualization.
In addition to guest operating system 32, one or more guest applications 36 execute “within” VM 20, although those skilled in the art will understand that execution of guest OS and guest application instructions occurs via virtualization software 15 and host platform 10. Guest application 36 may be any type of application designed to work with guest operating system 32. As generally understood in the art of virtualization, user input and output to and from VM 20 may be redirected by virtualization software 15 to a remote terminal (not shown) or through a terminal application (not shown) executing on console operating system 40.
Virtualization software 15 may include one or more software components and/or layers, possibly including one or more of the software components known in the field of virtual machine technology as “virtual machine monitors” (VMMs), “hypervisors,” or virtualization kernels (referred to herein as “VM kernels”). Because virtualization terminology has evolved over time and has not yet become fully standardized, these terms do not always provide clear distinctions between the software layers and components to which they refer. As used herein, the term, “virtualization software” is intended to generically refer to a software layer or component logically interposed between a virtual machine and the host platform.
In the virtualization system shown in FIG. 1, VMMs 50 are deployed on top of VM kernel 60. VM kernel 60 may be constructed specifically to provide efficient support for the VMs and directly (i.e., not using a general-purpose host OS, such as Linux or Windows) interfaces with the physical resources and devices making up host 10. Note that the VM kernel 60 is not the same as a kernel within the guest OS 32. As is well known, each typical operating system has its own OS kernel. Note also that VM kernel 60 can be viewed as being part of the host platform for the VM even though the configuration shown in FIG. 1 is commonly termed “non-hosted.”
In a different, well-known configuration (not shown) virtualization software 15 could include a general purpose operating system (not shown) instead of a VM kernel. Such a configuration is often referred to as a “hosted” virtualization system, with the general purpose operating system as the host OS. The host OS is configured to perform certain device input/output (I/O) operations for the various VMs executing on the system, alongside and sometimes at the request of the VMM. In this case, the host OS may be considered to be part of the virtualization software that enables the virtualization. The selection of the configuration of the virtualization software, i.e., whether hosted or not, or whether it is fully virtualized or para-virtualized, are made based on the relative advantages and disadvantages of each type, which are well known to those skilled in the art of virtualizing computer systems.
FIG. 2 illustrates VMs 20-1, 20-2 and VMMs 50-1, 50-2 transmitting network frames to network interface card (NIC) 17 of host 10-1 through virtual switch 65. Virtualization software 15 transmits network frames from VMs 20-1, 20-2 via virtual NICs (VNICs) 25-1, 25-2 to physical NIC 17 of host computer 10-1. Each VNICs 25-1, 25-2 is communicatively coupled to a corresponding virtual port 62, 64 of virtual switch 65. Virtual switch 65 is a logical collection of virtual ports 62, 64, and maintains a forwarding database (not shown) of VNIC addresses, e.g., MAC addresses. Each virtual port 62, 64, 66 is a logical rendezvous point for a corresponding VNIC and the software components that forward traffic to and from the VNICs. In this manner, virtual switch 65 determines how and where to route network frames transmitted to and from VNICs 25-1, 25-2 and NIC 17. Thus, virtual switch 65 functions as a software bridge that allows multiple VMs to share zero, one, or multiple physical NICs. If zero (i.e., no) physical NICs are installed on host 10-1, for example, then virtual switch 65 may function as a virtual network that connects VMs 20-1, 20-2 running on host 10-1.
Each VNIC 25-1, 25-2 is an emulated network device, presented by virtualization software 15 to VMs 20-1, 20-2 requiring network access. Thus, virtual switch 65 handles forwarding traffic between the VNICs 25-1, 25-2, connected to virtual switch 65 and possibly bridging to a physical network via one or more physical NICs. In general, virtual switches are capable of determining, based on a network frame's header, whether or not the frame is locally destined, and if it is locally destined, which virtual machines should receive the frame. Network administrators are generally required to manage the virtual switches 65 to configure these features. Since the number of virtual switches 65 are typically greater in number than their physical counterparts, the network administrator may be required to perform repetitive tasks of configuring many virtual switches 65.
One advantage of virtualization technology is that it allows a VM to be migrated from one physical host to another by powering down or suspending the VM on one host, and powering up or resuming the VM a different physical host. In this context, “suspending,” refers to the execution of the VM being temporarily or permanently halted by the virtualization software. It should be noted that the execution of a VM is frequently suspended even though it is “running.” A VM may be momentarily suspended, for example, in order to allow execution of another co-running VM to proceed. In contrast, “powering off” a VM refers to virtualizing the power-down procedure of a physical machine. As with a physical computer, a VM may be powered down in a methodical manner in which each process is notified by the OS of impending shut down, allowing each open application to save its data and exit, or the power down can be performed by simulating a power-off, in which case all running processes are terminated, losing any unsaved data or state associated with running processes. After powering off a VM, resumption of execution typically requires rebooting the guest OS and restarting any applications, whereas resuming execution of a suspended VM requires reloading the state into the VM and resuming execution.
When a VM is suspended, the processes are halted and the VM's state, including its memory contents, register settings, virtual device states, etc., may be written to a disk. In the example shown in FIG. 2, VM 20-2 may be migrated by suspending or powering off VM 20-2 on host 10-1 and resuming or powering on VM 20-2 on host 10-2, as represented by arrow 75. The term “migration” therefore refers to a process of moving a VM from one host to another by suspending or powering off a VM on one host and resuming or powering on that VM on a different host.
Unfortunately, migrating a VM from one host to another may involve some loss in state associated with the VNIC for the migrated VM. Conventionally, when VM 20-2 is migrated from host 10-1 to host 10-2 (as indicated by arrow 75), connection 56 between VNIC emulator 55-2 and virtual port 64 is lost, as indicated by cross 52, and a new connection 58 is established between VNIC emulator 55-3 and virtual port 66 on virtual switch 65′ implemented by virtualization software 15′ on host 10-2. The MAC address and other state information associated with VNIC 25-2 can be transferred to VNIC 25-3 as part of the attributes of the virtual devices making up VM 20-2, so that resumed VM 20-2 maintains its position on the network. However, VM 20-2 further connects to virtual port 66 of virtual switch 65′ on host 10-2, presuming new port 66 to offer similar network connectivity, but making no assumptions about any preservation of state not associated specifically with virtual NIC device 25-2 (e.g., MAC address, broadcast/multicast filter, etc). Thus, in the course of this VM migration process, state information that may be accumulated on virtual switch port 64 is typically lost.
In addition to these heretofore unrecognized problems, a network administrator who is viewing a virtual network from the switch point of view has no consistent topology to work with if VMs are migrating while he attempts to view and/or reconfigure the virtual network.